Jan Beulich [Tue, 5 Jan 2021 12:11:04 +0000 (13:11 +0100)]
x86/ACPI: don't invalidate S5 data when S3 wakeup vector cannot be determined
We can be more tolerant as long as the data collected from FACS is only
needed to enter S3. A prior change already added suitable checking to
acpi_enter_sleep().
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com>
(cherry picked from commit 16ca5b3f873f17f4fbdaecf46c133e1aa3d623b2)
Gbp-Pq: Name 0044-x86-ACPI-don-t-invalidate-S5-data-when-S3-wakeup-vec.patch
Jan Beulich [Tue, 5 Jan 2021 12:09:55 +0000 (13:09 +0100)]
x86/ACPI: fix S3 wakeup vector mapping
Use of __acpi_map_table() here was at least close to an abuse already
before, but it will now consistently return NULL here. Drop the layering
violation and use set_fixmap() directly. Re-use of the ACPI fixmap area
is hopefully going to remain "fine" for the time being.
Add checks to acpi_enter_sleep(): The vector now needs to be contained
within a single page, but the ACPI spec requires 64-byte alignment of
FACS anyway. Also bail if no wakeup vector was determined in the first
place, in part as preparation for a subsequent relaxation change.
Fixes: 1c4aa69ca1e1 ("xen/acpi: Rework acpi_os_map_memory() and acpi_os_unmap_memory()") Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com>
(cherry picked from commit 0f089bbf43ecce6f27576cb548ba4341d0ec46a8)
Gbp-Pq: Name 0043-x86-ACPI-fix-S3-wakeup-vector-mapping.patch
Jan Beulich [Tue, 24 Nov 2020 10:26:34 +0000 (11:26 +0100)]
x86/DMI: fix table mapping when one lives above 1Mb
Use of __acpi_map_table() is kind of an abuse here, and doesn't work
anymore for the majority of cases if any of the tables lives outside the
low first Mb. Keep this (ab)use only prior to reaching SYS_STATE_boot,
primarily to avoid needing to audit whether any of the calls here can
happen this early in the first place; quite likely this isn't necessary
at all - at least dmi_scan_machine() gets called late enough.
For the "normal" case, call __vmap() directly, despite effectively
duplicating acpi_os_map_memory(). There's one difference though: We
shouldn't need to establish UC- mappings, WP or r/o WB mappings ought to
be fine, as the tables are going to live in either RAM or ROM. Short of
having PAGE_HYPERVISOR_WP and wanting to map the tables r/o anyway, use
the latter of the two options. The r/o mapping implies some
constification of code elsewhere in the file. For code touched anyway
also switch to void (where possible) or uint8_t.
Fixes: 1c4aa69ca1e1 ("xen/acpi: Rework acpi_os_map_memory() and acpi_os_unmap_memory()") Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com>
(cherry picked from commit f390941a92f102ebbbbce1b54be206a602187fd7)
Gbp-Pq: Name 0042-x86-DMI-fix-table-mapping-when-one-lives-above-1Mb.patch
Jan Beulich [Tue, 24 Nov 2020 10:26:02 +0000 (11:26 +0100)]
x86/ACPI: fix mapping of FACS
acpi_fadt_parse_sleep_info() runs when the system is already in
SYS_STATE_boot. Hence its direct call to __acpi_map_table() won't work
anymore. This call should probably have been replaced long ago already,
as the layering violation hasn't been necessary for quite some time.
Fixes: 1c4aa69ca1e1 ("xen/acpi: Rework acpi_os_map_memory() and acpi_os_unmap_memory()") Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com>
(cherry picked from commit 8b6d55c1261820bb9db8d867ce9ee77397d05203)
Gbp-Pq: Name 0041-x86-ACPI-fix-mapping-of-FACS.patch
Use the solution described in [1] to replace the call to the 'date'
command with a version that uses SOURCE_DATE_EPOCH if available. This
is needed for reproducible builds.
Signed-off-by: Maximilian Engelhardt <maxi@daemonizer.de>
[Hans van Kranenburg]
Note: this patch is submitted upstream but not committed yet. We
expect that it gets in. Otherwise, we don't wait and already have it
here because I want to have the reproducible build work completed.
Gbp-Pq: Name 0040-docs-set-date-to-SOURCE_DATE_EPOCH-if-available.patch
docs: use predictable ordering in generated documentation
When the seq number is equal, sort by the title to get predictable
output ordering. This is useful for reproducible builds.
Signed-off-by: Maximilian Engelhardt <maxi@daemonizer.de> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
(cherry picked from commit e18dadc5b709290b8038a1cacb52bc3b3b69cf21)
Gbp-Pq: Name 0039-docs-use-predictable-ordering-in-generated-documenta.patch
x86/EFI: don't insert timestamp when SOURCE_DATE_EPOCH is defined
By default a timestamp gets added to the xen efi binary. Unfortunately
ld doesn't seem to provide a way to set a custom date, like from
SOURCE_DATE_EPOCH, so set a zero value for the timestamp (option
--no-insert-timestamp) if SOURCE_DATE_EPOCH is defined. This makes
reproducible builds possible.
This is an alternative to the patch suggested in [1]. This patch only
omits the timestamp when SOURCE_DATE_EPOCH is defined.
Signed-off-by: Maximilian Engelhardt <maxi@daemonizer.de> Acked-by: Jan Beulich <jbeulich@suse.com>
(cherry picked from commit ee41b5c450032ae7f2531e18cd0a73bf5fb48803)
Gbp-Pq: Name 0038-x86-EFI-don-t-insert-timestamp-when-SOURCE_DATE_EPOC.patch
In docs/misc/dump-core-format.txt there are a few more instances of
'informations'. I'll leave that up to someone who can properly determine
how those sentences should be constructed.
Signed-off-by: Diederik de Haas <didi.debian@cknow.org> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Acked-by: Jan Beulich <jbeulich@suse.com>
(cherry picked from commit ba6e78f0db820fbeea4df41fde4655020ca05928)
The BAD_MADT_ENTRY() macro is designed to work for all of the subtables
of the MADT. In the ACPI 5.1 version of the spec, the struct for the
GICC subtable (struct acpi_madt_generic_interrupt) is 76 bytes long; in
ACPI 6.0, the struct is 80 bytes long. But, there is only one definition
in ACPICA for this struct -- and that is the 6.0 version. Hence, when
BAD_MADT_ENTRY() compares the struct size to the length in the GICC
subtable, it fails if 5.1 structs are in use, and there are systems in
the wild that have them.
This patch adds the BAD_MADT_GICC_ENTRY() that checks the GICC subtable
only, accounting for the difference in specification versions that are
possible. The BAD_MADT_ENTRY() will continue to work as is for all other
MADT subtables.
This code is being added to an arm64 header file since that is currently
the only architecture using the GICC subtable of the MADT. As a GIC is
specific to ARM, it is also unlikely the subtable will be used elsewhere.
Fixes: aeb823bbacc2 ("ACPICA: ACPI 6.0: Add changes for FADT table.") Signed-off-by: Al Stone <al.stone@linaro.org> Acked-by: Will Deacon <will.deacon@arm.com> Acked-by: "Rafael J. Wysocki" <rjw@rjwysocki.net>
[catalin.marinas@arm.com: extra brackets around macro arguments] Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Julien Grall <julien.grall@arm.com> Signed-off-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Julien Grall <jgrall@amazon.com> Acked-by: Stefano Stabellini <sstabellini@kernel.org> Tested-by: Elliott Mitchell <ehem+xen@m5p.com>
(cherry picked from commit 7056f2f89f03f2f804ac7e776c7b2b000cd716cd)
Gbp-Pq: Name 0034-xen-arm-acpi-add-BAD_MADT_GICC_ENTRY-macro.patch
xen/arm: Check if the platform is not using ACPI before initializing Dom0less
Dom0less requires a device-tree. However, since commit 6e3e77120378
"xen/arm: setup: Relocate the Device-Tree later on in the boot", the
device-tree will not get unflatten when using ACPI.
This will lead to a crash during boot.
Given the complexity to setup dom0less with ACPI (for instance how to
assign device?), we should skip any code related to Dom0less when using
ACPI.
xen/arm: acpi: The fixmap area should always be cleared during failure/unmap
Commit 022387ee1ad3 "xen/arm: mm: Don't open-code Xen PT update in
{set, clear}_fixmap()" enforced that each set_fixmap() should be
paired with a clear_fixmap(). Any failure to follow the model would
result to a platform crash.
Unfortunately, the use of fixmap in the ACPI code was overlooked as it
is calling set_fixmap() but not clear_fixmap().
The function __acpi_os_map_table() is reworked so:
- We know before the mapping whether the fixmap region is big
enough for the mapping.
- It will fail if the fixmap is already in use. This is not a
change of behavior but clarifying the current expectation to avoid
hitting a BUG().
The function __acpi_os_unmap_table() will now call clear_fixmap().
xen/acpi: Rework acpi_os_map_memory() and acpi_os_unmap_memory()
The functions acpi_os_{un,}map_memory() are meant to be arch-agnostic
while the __acpi_os_{un,}map_memory() are meant to be arch-specific.
Currently, the former are still containing x86 specific code.
To avoid this rather strange split, the generic helpers are reworked so
they are arch-agnostic. This requires the introduction of a new helper
__acpi_os_unmap_memory() that will undo any mapping done by
__acpi_os_map_memory().
Currently, the arch-helper for unmap is basically a no-op so it only
returns whether the mapping was arch specific. But this will change
in the future.
Note that the x86 version of acpi_os_map_memory() was already able to
able the 1MB region. Hence why there is no addition of new code.
Elliott Mitchell [Mon, 12 Oct 2020 01:11:39 +0000 (18:11 -0700)]
tools/python: Pass linker to Python build process
Unexpectedly the environment variable which needs to be passed is
$LDSHARED and not $LD. Otherwise Python may find the build `ld` instead
of the host `ld`.
Replace $(LDFLAGS) with $(SHLIB_LDFLAGS) as Python needs shared objects
it can load at runtime, not executables.
This uses $(CC) instead of $(LD) since Python distutils appends $CFLAGS
to $LDFLAGS which breaks many linkers.
Signed-off-by: Elliott Mitchell <ehem+xen@m5p.com> Acked-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
(cherry picked from commit 17d192e0238d6c714e9f04593b59597b7090be38)
[ Hans van Kranenburg ]
Fixed cherry-pick conflict because we have LIBEXEC_LIB=$(LIBEXEC_LIB) in
between in the same lines. The line wrap mess makes it a bit hard to
follow.
Gbp-Pq: Name 0028-tools-python-Pass-linker-to-Python-build-process.patch
t/h/L/vif-common.sh: fix handle_iptable return value
A return statement without explicit value will return the value of the
last command executed before this line with return was encountered.
This is not what we want. return 0.
Closes: #955994 Fixes: 2e0814f971dd ("vif-common: disable handle_iptable") Reported-by: Samuel Thibault <sthibault@debian.org> Signed-off-by: Hans van Kranenburg <hans@knorrie.org>
Gbp-Pq: Name 0026-t-h-L-vif-common.sh-fix-handle_iptable-return-value.patch
Of the 3, both Python and pygrub appear to mostly be building just fine
cross-compiling. The OCAML portion is being troublesome, this is going
to cause bug reports elsewhere soon. The OCAML portion though can
already be disabled by setting OCAML_TOOLS=n and shouldn't have this
extra form of disabling.
Signed-off-by: Elliott Mitchell <ehem+xen@m5p.com> Acked-by: Christian Lindig <christian.lindig@citrix.com> Acked-by: Wei Liu <wl@xen.org>
(cherry picked from commit 69953e2856382274749b617125cc98ce38198463)
Gbp-Pq: Name 0025-tools-Partially-revert-Cross-compilation-fixes.patch
Ian Jackson [Fri, 22 Feb 2019 12:24:35 +0000 (12:24 +0000)]
pygrub: Specify -rpath LIBEXEC_LIB when building fsimage.so
If LIBEXEC_LIB is not on the default linker search path, the python
fsimage.so module fails to find libfsimage.so.
Add the relevant directory to the rpath explicitly.
(This situation occurs in the Debian package, where
--with-libexec-libdir is used to put each Xen version's libraries and
utilities in their own directory, to allow them to be coinstalled.)
Signed-off-by: Ian Jackson <ian.jackson@citrix.com>
Gbp-Pq: Name 0022-pygrub-Specify-rpath-LIBEXEC_LIB-when-building-fsima.patch
We install libfsimage in a non-standard path for Reasons.
(See debian/rules.)
This patch was originally part of `tools-pygrub-prefix.diff'
(eg commit 51657319be54) and included changes to the Makefile to
change the installation arrangements (we do that part in the rules now
since that is a lot less prone to conflicts when we update) and to
shared library rpath (which is now done in a separate patch).
(Commit message rewritten by Ian Jackson.)
Signed-off-by: Ian Jackson <ian.jackson@citrix.com>
squash! pygrub: Set sys.path and rpath
Ian Jackson [Thu, 21 Feb 2019 16:05:40 +0000 (16:05 +0000)]
hotplug-common: Do not adjust LD_LIBRARY_PATH
This is in the upstream script because on non-Debian systems, the
default install locations in /usr/local/lib might not be on the linker
path, and as a result the hotplug scripts would break.
A reason we might need it in Debian is our multiple version
coinstallation scheme. However, the hotplug scripts all call the
utilities via the wrappers, and the binaries are configured to load
from the right place anyway.
This setting is an annoyance because it requires libdir, which is an
arch-specific path but comes from a file we want to put in
xen-utils-common, an arch:all package.
So drop this setting.
Signed-off-by: Ian Jackson <ian.jackson@citrix.com>
Gbp-Pq: Name 0020-hotplug-common-Do-not-adjust-LD_LIBRARY_PATH.patch
Signed-off-by: Hans van Kranenburg <hans@knorrie.org> Acked-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Gbp-Pq: Name 0019-sysconfig.xencommons.in-Strip-and-debianize.patch
Also see Debian bug #894013. The current attempt at providing
anti-spoofing rules results in a situation that does not have any
effect. Also note that forwarding bridged traffic to iptables is not
enabled by default, and that for openvswitch users it does not make any
sense.
So, stop cluttering the live iptables ruleset.
This functionality seems to be introduced before 2004 and since then it
has never got some additional love.
It would be nice to have a proper discussion upstream about how Xen
could provide some anti mac/ip spoofing in the dom0. It does not seem to
be a trivial thing to do, since it requires having quite some knowledge
about what the domU is allowed to do or not (e.g. a domU can be a
router...).
Gbp-Pq: Name 0018-vif-common-disable-handle_iptable.patch
(XEN) Xen version 4.11.1 (Debian )
(@)
(gcc (Debian 8.2.0-13) 8.2.0) debug=n
Thu Jan 3 19:08:37 UTC 2019
I'd like to see:
(XEN) Xen version 4.11.1 (Debian 4.11.1-1~)
(pkg-xen-devel@lists.alioth.debian.org)
(gcc (Debian 8.2.0-13) 8.2.0) debug=n
Thu Jan 3 22:44:00 CET 2019
The substitution was broken since the great packaging refactoring,
because the directory in which the build is done changed.
Also, use the Maintainer address from debian/control instead of the most
recent changelog entry. If someone wants to use the address to ask a
question, they will end up at the team mailing list, which is better
than an individual person.
Gbp-Pq: Name 0017-Fix-empty-fields-in-first-hypervisor-log-line.patch
Ian Jackson [Fri, 12 Oct 2018 17:17:10 +0000 (17:17 +0000)]
shim: Provide separate install-shim target
When building on a 32-bit userland, the user wants to build 32-bit
tools and a 64-bit hypervisor. This involves setting XEN_TARGET_ARCH
to different values for the tools build and the hypervisor build.
So the user must invoke the tools build and the hypervisor build
separately.
However, although the shim is done by the tools/firmware Makefile, its
bitness needs to be the same as the hypervisor, not the same as the
tools. When run with XEN_TARGET_ARCH=x86_32, it it skipped, which is
wrong.
So the user must invoke the shim build separately. This can be done
with
make -C tools/firmware/xen-dir XEN_TARGET_ARCH=x86_64
However, tools/firmware/xen-dir has no `install' target. The
installation of all `firmware' is done in tools/firmware/Makefile. It
might be possible to fix this, but it is not trivial. For example,
the definitions of INST_DIR and DEBG_DIR would need to be copied, as
would an appropriate $(INSTALL_DIR) call.
For now, provide an `install-shim' target in tools/firmware/Makefile.
This has to be called from `install' of course. We can't make it
a dependency of `install' because it might be run before `all' has
completed. We could make it depend on a `shim' target but such
a target is nearly impossible to write because everything is done by
the inflexible subdir-$@ machinery.
The overally result of this patch is that existing make invocations
work as before. But additionally, the user can say
make -C tools/firmware install-shim XEN_TARGET_ARCH=x86_64
to install the shim. The user must have built it already.
Unlike the build rune, this install-rune is properly conditional
so it is OK to call on ARM.
What a mess.
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Gbp-Pq: Name 0015-shim-Provide-separate-install-shim-target.patch
This makes it easier to disable the shim build. (In Debian we need to
build the shim separately because it needs different compiler flags
and a different XEN_COMPILE_ARCH.
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Gbp-Pq: Name 0013-tools-firmware-Makfile-Respect-caller-s-CONFIG_PV_SH.patch
This is due to the combination of GCC6, and Debian's decision to
enable some hardening flags by default (to try to make runtime
addresses less predictable):
https://wiki.debian.org/Hardening/PIEByDefaultTransition
This is of no benefit for the x86 instruction emulator test, which is
a rebuild of the emulator code for testing purposes only. So pass
options to disable this.
These options will be no-ops if they are the same as the compiler
default.
On amd64, the -fno-pic breaks the build in a different way. So do
this only on i386.
Signed-off-by: Ian Jackson <ian.jackson@citrix.com> CC: Jan Beulich <jbeulich@suse.com> CC: Andrew Cooper <andrew.cooper3@citrix.com>
Gbp-Pq: Topic misc
Gbp-Pq: Name toolstestsx86_emulator-pass--no-pie--fno.patch
* Update to new upstream version 4.14.5+86-g1c354767d5, which also contains
security fixes for the following issues: (Closes: #1021668)
- Xenstore: guests can let run xenstored out of memory
XSA-326 CVE-2022-42311 CVE-2022-42312 CVE-2022-42313 CVE-2022-42314
CVE-2022-42315 CVE-2022-42316 CVE-2022-42317 CVE-2022-42318
- insufficient TLB flush for x86 PV guests in shadow mode
XSA-408 CVE-2022-33745
- Arm: unbounded memory consumption for 2nd-level page tables
XSA-409 CVE-2022-33747
- P2M pool freeing may take excessively long
XSA-410 CVE-2022-33746
- lock order inversion in transitive grant copy handling
XSA-411 CVE-2022-33748
- Xenstore: Guests can crash xenstored
XSA-414 CVE-2022-42309
- Xenstore: Guests can create orphaned Xenstore nodes
XSA-415 CVE-2022-42310
- Xenstore: Guests can cause Xenstore to not free temporary memory
XSA-416 CVE-2022-42319
- Xenstore: Guests can get access to Xenstore nodes of deleted domains
XSA-417 CVE-2022-42320
- Xenstore: Guests can crash xenstored via exhausting the stack
XSA-418 CVE-2022-42321
- Xenstore: Cooperating guests can create arbitrary numbers of nodes
XSA-419 CVE-2022-42322 CVE-2022-42323
- Oxenstored 32->31 bit integer truncation issues
XSA-420 CVE-2022-42324
- Xenstore: Guests can create arbitrary number of nodes via transactions
XSA-421 CVE-2022-42325 CVE-2022-42326
* The upstream Xen changes now also contain the first mentioned patch of
XSA-403 ("Linux disk/nic frontends data leaks") for stable branch lines.
For more information, please refer to the XSA-403 advisory text.
* Note that the following XSA are not listed, because...
- XSA-412 only applies to Xen 4.16 and newer
- XSA-413 applies to XAPI which is not included in Debian
* Correct a typo in the previous changelog entry.
Jan Beulich [Tue, 5 Jan 2021 12:11:04 +0000 (13:11 +0100)]
x86/ACPI: don't invalidate S5 data when S3 wakeup vector cannot be determined
We can be more tolerant as long as the data collected from FACS is only
needed to enter S3. A prior change already added suitable checking to
acpi_enter_sleep().
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com>
(cherry picked from commit 16ca5b3f873f17f4fbdaecf46c133e1aa3d623b2)
Gbp-Pq: Name 0044-x86-ACPI-don-t-invalidate-S5-data-when-S3-wakeup-vec.patch
Jan Beulich [Tue, 5 Jan 2021 12:09:55 +0000 (13:09 +0100)]
x86/ACPI: fix S3 wakeup vector mapping
Use of __acpi_map_table() here was at least close to an abuse already
before, but it will now consistently return NULL here. Drop the layering
violation and use set_fixmap() directly. Re-use of the ACPI fixmap area
is hopefully going to remain "fine" for the time being.
Add checks to acpi_enter_sleep(): The vector now needs to be contained
within a single page, but the ACPI spec requires 64-byte alignment of
FACS anyway. Also bail if no wakeup vector was determined in the first
place, in part as preparation for a subsequent relaxation change.
Fixes: 1c4aa69ca1e1 ("xen/acpi: Rework acpi_os_map_memory() and acpi_os_unmap_memory()") Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com>
(cherry picked from commit 0f089bbf43ecce6f27576cb548ba4341d0ec46a8)
Gbp-Pq: Name 0043-x86-ACPI-fix-S3-wakeup-vector-mapping.patch
Jan Beulich [Tue, 24 Nov 2020 10:26:34 +0000 (11:26 +0100)]
x86/DMI: fix table mapping when one lives above 1Mb
Use of __acpi_map_table() is kind of an abuse here, and doesn't work
anymore for the majority of cases if any of the tables lives outside the
low first Mb. Keep this (ab)use only prior to reaching SYS_STATE_boot,
primarily to avoid needing to audit whether any of the calls here can
happen this early in the first place; quite likely this isn't necessary
at all - at least dmi_scan_machine() gets called late enough.
For the "normal" case, call __vmap() directly, despite effectively
duplicating acpi_os_map_memory(). There's one difference though: We
shouldn't need to establish UC- mappings, WP or r/o WB mappings ought to
be fine, as the tables are going to live in either RAM or ROM. Short of
having PAGE_HYPERVISOR_WP and wanting to map the tables r/o anyway, use
the latter of the two options. The r/o mapping implies some
constification of code elsewhere in the file. For code touched anyway
also switch to void (where possible) or uint8_t.
Fixes: 1c4aa69ca1e1 ("xen/acpi: Rework acpi_os_map_memory() and acpi_os_unmap_memory()") Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com>
(cherry picked from commit f390941a92f102ebbbbce1b54be206a602187fd7)
Gbp-Pq: Name 0042-x86-DMI-fix-table-mapping-when-one-lives-above-1Mb.patch
Jan Beulich [Tue, 24 Nov 2020 10:26:02 +0000 (11:26 +0100)]
x86/ACPI: fix mapping of FACS
acpi_fadt_parse_sleep_info() runs when the system is already in
SYS_STATE_boot. Hence its direct call to __acpi_map_table() won't work
anymore. This call should probably have been replaced long ago already,
as the layering violation hasn't been necessary for quite some time.
Fixes: 1c4aa69ca1e1 ("xen/acpi: Rework acpi_os_map_memory() and acpi_os_unmap_memory()") Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com>
(cherry picked from commit 8b6d55c1261820bb9db8d867ce9ee77397d05203)
Gbp-Pq: Name 0041-x86-ACPI-fix-mapping-of-FACS.patch
Use the solution described in [1] to replace the call to the 'date'
command with a version that uses SOURCE_DATE_EPOCH if available. This
is needed for reproducible builds.
Signed-off-by: Maximilian Engelhardt <maxi@daemonizer.de>
[Hans van Kranenburg]
Note: this patch is submitted upstream but not committed yet. We
expect that it gets in. Otherwise, we don't wait and already have it
here because I want to have the reproducible build work completed.
Gbp-Pq: Name 0040-docs-set-date-to-SOURCE_DATE_EPOCH-if-available.patch
docs: use predictable ordering in generated documentation
When the seq number is equal, sort by the title to get predictable
output ordering. This is useful for reproducible builds.
Signed-off-by: Maximilian Engelhardt <maxi@daemonizer.de> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
(cherry picked from commit e18dadc5b709290b8038a1cacb52bc3b3b69cf21)
Gbp-Pq: Name 0039-docs-use-predictable-ordering-in-generated-documenta.patch
x86/EFI: don't insert timestamp when SOURCE_DATE_EPOCH is defined
By default a timestamp gets added to the xen efi binary. Unfortunately
ld doesn't seem to provide a way to set a custom date, like from
SOURCE_DATE_EPOCH, so set a zero value for the timestamp (option
--no-insert-timestamp) if SOURCE_DATE_EPOCH is defined. This makes
reproducible builds possible.
This is an alternative to the patch suggested in [1]. This patch only
omits the timestamp when SOURCE_DATE_EPOCH is defined.
Signed-off-by: Maximilian Engelhardt <maxi@daemonizer.de> Acked-by: Jan Beulich <jbeulich@suse.com>
(cherry picked from commit ee41b5c450032ae7f2531e18cd0a73bf5fb48803)
Gbp-Pq: Name 0038-x86-EFI-don-t-insert-timestamp-when-SOURCE_DATE_EPOC.patch
In docs/misc/dump-core-format.txt there are a few more instances of
'informations'. I'll leave that up to someone who can properly determine
how those sentences should be constructed.
Signed-off-by: Diederik de Haas <didi.debian@cknow.org> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Acked-by: Jan Beulich <jbeulich@suse.com>
(cherry picked from commit ba6e78f0db820fbeea4df41fde4655020ca05928)
The BAD_MADT_ENTRY() macro is designed to work for all of the subtables
of the MADT. In the ACPI 5.1 version of the spec, the struct for the
GICC subtable (struct acpi_madt_generic_interrupt) is 76 bytes long; in
ACPI 6.0, the struct is 80 bytes long. But, there is only one definition
in ACPICA for this struct -- and that is the 6.0 version. Hence, when
BAD_MADT_ENTRY() compares the struct size to the length in the GICC
subtable, it fails if 5.1 structs are in use, and there are systems in
the wild that have them.
This patch adds the BAD_MADT_GICC_ENTRY() that checks the GICC subtable
only, accounting for the difference in specification versions that are
possible. The BAD_MADT_ENTRY() will continue to work as is for all other
MADT subtables.
This code is being added to an arm64 header file since that is currently
the only architecture using the GICC subtable of the MADT. As a GIC is
specific to ARM, it is also unlikely the subtable will be used elsewhere.
Fixes: aeb823bbacc2 ("ACPICA: ACPI 6.0: Add changes for FADT table.") Signed-off-by: Al Stone <al.stone@linaro.org> Acked-by: Will Deacon <will.deacon@arm.com> Acked-by: "Rafael J. Wysocki" <rjw@rjwysocki.net>
[catalin.marinas@arm.com: extra brackets around macro arguments] Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Julien Grall <julien.grall@arm.com> Signed-off-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Julien Grall <jgrall@amazon.com> Acked-by: Stefano Stabellini <sstabellini@kernel.org> Tested-by: Elliott Mitchell <ehem+xen@m5p.com>
(cherry picked from commit 7056f2f89f03f2f804ac7e776c7b2b000cd716cd)
Gbp-Pq: Name 0034-xen-arm-acpi-add-BAD_MADT_GICC_ENTRY-macro.patch
xen/arm: Check if the platform is not using ACPI before initializing Dom0less
Dom0less requires a device-tree. However, since commit 6e3e77120378
"xen/arm: setup: Relocate the Device-Tree later on in the boot", the
device-tree will not get unflatten when using ACPI.
This will lead to a crash during boot.
Given the complexity to setup dom0less with ACPI (for instance how to
assign device?), we should skip any code related to Dom0less when using
ACPI.
xen/arm: acpi: The fixmap area should always be cleared during failure/unmap
Commit 022387ee1ad3 "xen/arm: mm: Don't open-code Xen PT update in
{set, clear}_fixmap()" enforced that each set_fixmap() should be
paired with a clear_fixmap(). Any failure to follow the model would
result to a platform crash.
Unfortunately, the use of fixmap in the ACPI code was overlooked as it
is calling set_fixmap() but not clear_fixmap().
The function __acpi_os_map_table() is reworked so:
- We know before the mapping whether the fixmap region is big
enough for the mapping.
- It will fail if the fixmap is already in use. This is not a
change of behavior but clarifying the current expectation to avoid
hitting a BUG().
The function __acpi_os_unmap_table() will now call clear_fixmap().
xen/acpi: Rework acpi_os_map_memory() and acpi_os_unmap_memory()
The functions acpi_os_{un,}map_memory() are meant to be arch-agnostic
while the __acpi_os_{un,}map_memory() are meant to be arch-specific.
Currently, the former are still containing x86 specific code.
To avoid this rather strange split, the generic helpers are reworked so
they are arch-agnostic. This requires the introduction of a new helper
__acpi_os_unmap_memory() that will undo any mapping done by
__acpi_os_map_memory().
Currently, the arch-helper for unmap is basically a no-op so it only
returns whether the mapping was arch specific. But this will change
in the future.
Note that the x86 version of acpi_os_map_memory() was already able to
able the 1MB region. Hence why there is no addition of new code.
Elliott Mitchell [Mon, 12 Oct 2020 01:11:39 +0000 (18:11 -0700)]
tools/python: Pass linker to Python build process
Unexpectedly the environment variable which needs to be passed is
$LDSHARED and not $LD. Otherwise Python may find the build `ld` instead
of the host `ld`.
Replace $(LDFLAGS) with $(SHLIB_LDFLAGS) as Python needs shared objects
it can load at runtime, not executables.
This uses $(CC) instead of $(LD) since Python distutils appends $CFLAGS
to $LDFLAGS which breaks many linkers.
Signed-off-by: Elliott Mitchell <ehem+xen@m5p.com> Acked-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
(cherry picked from commit 17d192e0238d6c714e9f04593b59597b7090be38)
[ Hans van Kranenburg ]
Fixed cherry-pick conflict because we have LIBEXEC_LIB=$(LIBEXEC_LIB) in
between in the same lines. The line wrap mess makes it a bit hard to
follow.
Gbp-Pq: Name 0028-tools-python-Pass-linker-to-Python-build-process.patch
t/h/L/vif-common.sh: fix handle_iptable return value
A return statement without explicit value will return the value of the
last command executed before this line with return was encountered.
This is not what we want. return 0.
Closes: #955994 Fixes: 2e0814f971dd ("vif-common: disable handle_iptable") Reported-by: Samuel Thibault <sthibault@debian.org> Signed-off-by: Hans van Kranenburg <hans@knorrie.org>
Gbp-Pq: Name 0026-t-h-L-vif-common.sh-fix-handle_iptable-return-value.patch
Of the 3, both Python and pygrub appear to mostly be building just fine
cross-compiling. The OCAML portion is being troublesome, this is going
to cause bug reports elsewhere soon. The OCAML portion though can
already be disabled by setting OCAML_TOOLS=n and shouldn't have this
extra form of disabling.
Signed-off-by: Elliott Mitchell <ehem+xen@m5p.com> Acked-by: Christian Lindig <christian.lindig@citrix.com> Acked-by: Wei Liu <wl@xen.org>
(cherry picked from commit 69953e2856382274749b617125cc98ce38198463)
Gbp-Pq: Name 0025-tools-Partially-revert-Cross-compilation-fixes.patch
Ian Jackson [Fri, 22 Feb 2019 12:24:35 +0000 (12:24 +0000)]
pygrub: Specify -rpath LIBEXEC_LIB when building fsimage.so
If LIBEXEC_LIB is not on the default linker search path, the python
fsimage.so module fails to find libfsimage.so.
Add the relevant directory to the rpath explicitly.
(This situation occurs in the Debian package, where
--with-libexec-libdir is used to put each Xen version's libraries and
utilities in their own directory, to allow them to be coinstalled.)
Signed-off-by: Ian Jackson <ian.jackson@citrix.com>
Gbp-Pq: Name 0022-pygrub-Specify-rpath-LIBEXEC_LIB-when-building-fsima.patch
We install libfsimage in a non-standard path for Reasons.
(See debian/rules.)
This patch was originally part of `tools-pygrub-prefix.diff'
(eg commit 51657319be54) and included changes to the Makefile to
change the installation arrangements (we do that part in the rules now
since that is a lot less prone to conflicts when we update) and to
shared library rpath (which is now done in a separate patch).
(Commit message rewritten by Ian Jackson.)
Signed-off-by: Ian Jackson <ian.jackson@citrix.com>
squash! pygrub: Set sys.path and rpath
Ian Jackson [Thu, 21 Feb 2019 16:05:40 +0000 (16:05 +0000)]
hotplug-common: Do not adjust LD_LIBRARY_PATH
This is in the upstream script because on non-Debian systems, the
default install locations in /usr/local/lib might not be on the linker
path, and as a result the hotplug scripts would break.
A reason we might need it in Debian is our multiple version
coinstallation scheme. However, the hotplug scripts all call the
utilities via the wrappers, and the binaries are configured to load
from the right place anyway.
This setting is an annoyance because it requires libdir, which is an
arch-specific path but comes from a file we want to put in
xen-utils-common, an arch:all package.
So drop this setting.
Signed-off-by: Ian Jackson <ian.jackson@citrix.com>
Gbp-Pq: Name 0020-hotplug-common-Do-not-adjust-LD_LIBRARY_PATH.patch
Signed-off-by: Hans van Kranenburg <hans@knorrie.org> Acked-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Gbp-Pq: Name 0019-sysconfig.xencommons.in-Strip-and-debianize.patch
Also see Debian bug #894013. The current attempt at providing
anti-spoofing rules results in a situation that does not have any
effect. Also note that forwarding bridged traffic to iptables is not
enabled by default, and that for openvswitch users it does not make any
sense.
So, stop cluttering the live iptables ruleset.
This functionality seems to be introduced before 2004 and since then it
has never got some additional love.
It would be nice to have a proper discussion upstream about how Xen
could provide some anti mac/ip spoofing in the dom0. It does not seem to
be a trivial thing to do, since it requires having quite some knowledge
about what the domU is allowed to do or not (e.g. a domU can be a
router...).
Gbp-Pq: Name 0018-vif-common-disable-handle_iptable.patch
(XEN) Xen version 4.11.1 (Debian )
(@)
(gcc (Debian 8.2.0-13) 8.2.0) debug=n
Thu Jan 3 19:08:37 UTC 2019
I'd like to see:
(XEN) Xen version 4.11.1 (Debian 4.11.1-1~)
(pkg-xen-devel@lists.alioth.debian.org)
(gcc (Debian 8.2.0-13) 8.2.0) debug=n
Thu Jan 3 22:44:00 CET 2019
The substitution was broken since the great packaging refactoring,
because the directory in which the build is done changed.
Also, use the Maintainer address from debian/control instead of the most
recent changelog entry. If someone wants to use the address to ask a
question, they will end up at the team mailing list, which is better
than an individual person.
Gbp-Pq: Name 0017-Fix-empty-fields-in-first-hypervisor-log-line.patch
Ian Jackson [Fri, 12 Oct 2018 17:17:10 +0000 (17:17 +0000)]
shim: Provide separate install-shim target
When building on a 32-bit userland, the user wants to build 32-bit
tools and a 64-bit hypervisor. This involves setting XEN_TARGET_ARCH
to different values for the tools build and the hypervisor build.
So the user must invoke the tools build and the hypervisor build
separately.
However, although the shim is done by the tools/firmware Makefile, its
bitness needs to be the same as the hypervisor, not the same as the
tools. When run with XEN_TARGET_ARCH=x86_32, it it skipped, which is
wrong.
So the user must invoke the shim build separately. This can be done
with
make -C tools/firmware/xen-dir XEN_TARGET_ARCH=x86_64
However, tools/firmware/xen-dir has no `install' target. The
installation of all `firmware' is done in tools/firmware/Makefile. It
might be possible to fix this, but it is not trivial. For example,
the definitions of INST_DIR and DEBG_DIR would need to be copied, as
would an appropriate $(INSTALL_DIR) call.
For now, provide an `install-shim' target in tools/firmware/Makefile.
This has to be called from `install' of course. We can't make it
a dependency of `install' because it might be run before `all' has
completed. We could make it depend on a `shim' target but such
a target is nearly impossible to write because everything is done by
the inflexible subdir-$@ machinery.
The overally result of this patch is that existing make invocations
work as before. But additionally, the user can say
make -C tools/firmware install-shim XEN_TARGET_ARCH=x86_64
to install the shim. The user must have built it already.
Unlike the build rune, this install-rune is properly conditional
so it is OK to call on ARM.
What a mess.
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Gbp-Pq: Name 0015-shim-Provide-separate-install-shim-target.patch
This makes it easier to disable the shim build. (In Debian we need to
build the shim separately because it needs different compiler flags
and a different XEN_COMPILE_ARCH.
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Gbp-Pq: Name 0013-tools-firmware-Makfile-Respect-caller-s-CONFIG_PV_SH.patch
This is due to the combination of GCC6, and Debian's decision to
enable some hardening flags by default (to try to make runtime
addresses less predictable):
https://wiki.debian.org/Hardening/PIEByDefaultTransition
This is of no benefit for the x86 instruction emulator test, which is
a rebuild of the emulator code for testing purposes only. So pass
options to disable this.
These options will be no-ops if they are the same as the compiler
default.
On amd64, the -fno-pic breaks the build in a different way. So do
this only on i386.
Signed-off-by: Ian Jackson <ian.jackson@citrix.com> CC: Jan Beulich <jbeulich@suse.com> CC: Andrew Cooper <andrew.cooper3@citrix.com>
Gbp-Pq: Topic misc
Gbp-Pq: Name toolstestsx86_emulator-pass--no-pie--fno.patch
* Update to new upstream version 4.14.5+24-g87d90d511c, which also contains
security fixes for the following issues:
for the following issues:
- x86 pv: Race condition in typeref acquisition
XSA-401 CVE-2022-26362
- x86 pv: Insufficient care with non-coherent mappings
XSA-402 CVE-2022-26363 CVE-2022-26364
- x86: MMIO Stale Data vulnerabilities
XSA-404 CVE-2022-21123 CVE-2022-21125 CVE-2022-21166
- Retbleed - arbitrary speculative code execution with return instructions
XSA-407 CVE-2022-23816 CVE-2022-23825 CVE-2022-29900
* Note that the following XSA are not listed, because...
- XSA-403 patches are not applied to stable branch lines.
- XSA-405 and XSA-406 have patches for the Linux kernel.
projects / xen.git / log